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(54) Single authentication for a plurality of services 



(57) Processing system and method for improving 
the efficiency of user authentication in a computing en- 
vironment. It is proposed to receive authentication infor- 



mation upon initialisation of a first service by an end user 
and to generate a security for initialisation of further sub- 
sequent services through the same end user without re- 
peated submitted of authentication information. 
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EP 1 315 064 A1 
Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to a processing system and a method for handling a plurality of services with 
only a single authentication. 

BACKGROUND OF INVENTION 

[0002] Data processing devices are used for the widest range of increasingly versatile applications. P-'ojding services 
andna from e g editing of text documents or spread sheet applications to complex software systems, e.g. cornputer- 
S dS systems o' systems adapted to manufacturing, purchasing, computer-aided bankmg. etc Further, m- 
c easingly c^r^pS X software applications are employed in the f.eid of personal services, e.g for P«--^' ^^^^ 
izaSn mobile communication applications like mobile telephones or hand-held computmg devices, or other serv.ces 

orovided or computer networks like the Internet. t^i^^^ 

roOOSr The more elements are involved in a computer-supported service environment where f"7""=^^'°" f j^^! 
Sace over a computer networks, the more important it is to ensure appropriate authentication of each ^uch a 

system to avoid abuse of user-specific, personal data or any other data being related to the correct operation of the 

roToT^Hrever. While the number of computer-supported applications is signmcantly increasir^g over ^^^^^^^ 
and methods for appropriate authentication of a user of such a system still rely on an individual authentication of th^^^ 
userTor each single seLe. In other words, when accessing multiple services in the <:°7"*'"9 «7'^°7^;^;.;'^^ "^^^ 
usuL 7y has to separately authenticate himself for each one of these sen/ices to obtain the related funct^nality. 
[00051 TyS for each single service an associated log-in mechanism will require authentication of t^e user e 
though submissL of a user name and a user password, as for security reasons it is often not acceptable to keep 
passwords in related memories and pass it between different service applications. * k =c =>n ,.n 

[OOoT While an authentication functionality may be easily implemented in a "closed environment, such as a op- 
era°nq system on a personal computer or a main frame, where applications and interactions can easily exchange data, 
fnl diSed application like an' application carried out using a plurality of data processing devices m a computer 
network the realization of an authentication functionality may become complex and cumbersome. 
[iTm fa user interacts with d^rfferent services on different data processing devices, currently an individual authen^ 
tication is required upon initialisation of each single service on the respective data processing devices. This applies 
even if the user previously submitted this information to a plurality data processing devices. . ^ • . 

[0008] Moreover, as authentication mechanism of the individual services running on the data P«---"g^^^^^^^^^ 
rnay differ authentication procedures are further complicated and it becomes impossible to provide an appropriate 

PorstiraSeV^^^^^^^^^^^^^ 

a session or interaction between the user and the computing environment, which each time interrupts a provision of 
services to the user, thereby reducing efficiency of user interaction. 

SUMMARY OF INVENTION 

roOIOl in view of the above, it is desirable to improve the efficiency of user authentication in a computing environment. 
001 1 According to an example, managing a plurality of sen^ices at a session management unit, 
authentication information from a session processing unit adapted to handle a service session ^'v-ded mto a pk.r^^^^^^^ 
of services upon initialisation of a first service, and - returning a security token for initialisation of each subsequen 
service of the service session without repeated submission of authentication information. Thus. e.g. a user does not 
need to repeatedly submit authorisation information for different services. »«om»h nni« after suc- 

[0012] Advantageously returning the security token to the session processing unit may be effected only after sue 
cessful verification of the authentication information. Thus, it can be avoided that. e.g.. a fraudulent user obtains a 
security token without submitting valid authentication information. 

[0013] Further, a service host may be identified for each service request submitted by the session Processmg unit 
and the service request may be forwarded to the identified service host. Thus, e.g. a plurality of service hosts may be 
involved in providing services while avoiding repeated authentication of a user. 

ra01 41 service data may be received at the session management unit in response to the processing of the service 
request at th^ sen,ice host for subsequent fonvarding to the session processing unit. Thus, an information exchange 
bereinihe serce host and the session processing unit may be channelled through the ^^^^^^^^^^^Z'^^^L 
[OoTI] Alternatively, or in addition thereto, a direct forwarding of service data from the service host to the session 
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processing unit may be effected in response to the processing of the service, e.g., to avoid resource intensive routing 
of data through the session management unit. 

[0016] A session context information may be maintained, comprising at least the security token assigned for the 
service session, the authentication information, a list of services activated during the service session, and a list of 
connection points to related service hosts. 

[0017] Further, the session context information may be maintained in a centralized manner at the session manage- 
ment unit. Alternatively or in addition thereto, the session context information may be maintained in a distributed manner 
at the service hosts. 

[0018] Further, at least one service connection may be returned to a service host in addition to the security token for 
direct contact of the session processing unit to the at least one service host. 

[001 9] The session processing unit may be located at a client side and the session management unit may be located 
at a server side to remotely communicate with the session processing unit. Accordingly, the invention may be realized 
in a distributed system. 

[0020] According to another example, handling, at a session processing unit, a service session divided into a plurality 
of services may include: - transmitting authentication information to a session management unit upon initialisation of 
a first service; and - receiving a security token for initialisation of each subsequent service of the service session without 
repeated submission of authentication information. 

[0021] Further, it may be evaluated whether a new service request requires a new application module, further in- 
stalling the new application module at the session processing unit in the affirmative case, and assigning the session 
token and optionally service connection points to the newly installed application module. 

[0022] An authentication window may be set up for input of authentication data at a display, and the authentication 
window may be set up as a browser window. At least one of the services of a service session may be a Web service 
and the Web service may be a browser for browsing through data in a network of data processing devices. 
[0023] According to another example, a program may have instaictions for carrying out the above operations. Further, 
a computer readable medium may be provided, in which a program is embodied, where the program is to make a 
computer execute the above operations. A computer program product may comprise this computer readable medium. 
[0024] Further embodiments of the invention are disclosed in the claims, 

DESCRIPTION OF DRAWING 



[0025] 



Fig. 1 



shows a schematic diagram of a processing system adapted to handle a plurality of services 
according to the present Invention; 



Fig. 2 



shows a flowchart of a method for handling a plurality of services according to the present 
invention; 



Fig. 3 



illustrates session processing context from the viewpoint of an endues in the sense of the 
present invention; 



Fig. 4 



illustrates a session management context from- the viewpoint of a session management do- 
main in the sense of the present invention; 



Fig. 5 



shows a flowchart of a further method for handling a plurality of services according to the 
present invention; 



Fig- 6 



shows a flowchart of a method for terminating a plurality of sen/ices according to the present 
invention; 



Fig. 7 



illustrate different scenarios for interaction between the session processing/handling domain 
and the session context/service domain according to the present invention; in particular for a 
client server distributed computing environments; 



Fig. 8 



illustrates the combined provision of security token and of service connection point(s) accord- 
ing to the present invention; 



Fig. 9 



illustrates the combined provision of a security token and related service connection point(s) 
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together with a service support verification according to the present invention; 

Fig. 1 0 shows a flowchart for extending the available functionality at the end user side for the provision 

of additional services without repeated authentication according to the present invention; 

5 

Fig. 11 illustrates different ways to achieve sen/ice support evaluation according to the present in- 

vention; 

Fig. 1 2 shows a client-service system using the single authentication process for a plurality of services 

10 according to the present invention; 

Fig. 1 3 illustrates the interaction between a session handling domain and a service managing domain 

for a distributed client-service system; and 



15 



Figs. 1 4(a) and 1 4(b) give a more detailed insight into the interaction between the session handling domain and the 
session management/processing domain according to Fig. 13. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 

20 [0026] In the following an embodiment of the present invention will be described with respect to Fig. 1 . 

[0027] As shown in Fig. 1 , the embodiment realises a processing system 1 00 dividing into a session processing unit 
11 0 and a session management unit 1 20. The session processing unit is adapted to provide and use specific function- 
alities with respect to different services to an end user. On the other hand, the session management unit 1 20 is adapted 
to provide those functionalities with respect to service(s) not being handled at the end user side, such as administration 

25 of user data, authentication information verification, identification of the requested service{s) etc. 

[0028] As shown in Fig. 1 , the session processing unit is arranged to submit a security code, e.g., a password and 
a user name, to the session management unit for subsequent verification. In response to the submitted security code 
the session management unit 120 will then provide a security token to the session processing unit 110. Further, the 
session processing unit 11 0 is adapted to use this security token for subsequent interaction with the session manage- 

30 ment unit 1 20 such as request of a further service(s) without a repeated or authentication or in other words repeated 
submission of user name and passwords. 

[0029] The present embodiment aims at improving the efficiency of user authentication in a computing environment. 
Repeated user authorization operations are cumbersome and may deter a user from requesting services. 
[0030] To avoid repeated user authorization operations it should be understood that each single service typically 
35 divides into different service aspects of processing, e.g., I/O functionality, data display functionality, computing, etc., 
and further service management, e.g., administration of user data, password data, etc. Also, sen/ice management 
relates to the question where a specific request for a service will actually be processed, e.g., on which data processing 
system in a distributed computing environment. 

[0031] From the above, it should be clear that end users may have access to either a single device or a plurality of 
40 devices being adapted to service processing, e.g., user authentication, data display, etc. 

[0032] On the other hand computing device(s) handling service management are not under control of end users. 
Therefore, an end user has to authenticate towards the service management domain - i.e., the computing device(s) 
handling service management and sen/ice provision to end users. However, within this service management domain 
not for every single data exchange/service activation a related authentication is necessary 
45 [0033] The consequence from this is that once an end user has achieved a first successful authentication towards 
the service management domain, there exists at least one data processing system in this domain - e.g., access or 
entry server - that has verified the correctness of the authentication information. From this, it becomes clear that a 
repeated authentication towards a further unit in the service management domain becomes obsolete when information 
about a first valid authentication within the service management domain is transparent to all other units in this domain 
50 after such a successful authentication. 

[0034] A further operation towards the achievement eliminating repeated user authentication operations is then the 
establishment of a mechanism that allows the end user to indicate to each data processing device in the service 
management domain that it has already achieved a successful authentication during a subsequent access to this 
domain, 

55 [0035] Heretofore, it is proposed to receive authentication information, e.g., a user password and a user name, upon 
initialisation of a first service of a user, and then to generate a security item equivalently referred to as security token 
or security code in the following. 

[0036] Upon initialisation of a further service the end user may then use this security token for access to the service 
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management domain simply by adding the security token to the service request before submission of the service 
request. 

[0037] Further upon receipt of the service request expanded by the security token each data processing device in 
the service management domain - e.g., without restricting of the scope of the present invention a single computing 
5 device or a plurality of computing devices where a first computing device is a service management device and other 
devices are service host devices actually providing the services - may then use the security token for authentication 
before actually providing the related service(s). 

[0038] Here, contrary to existing authentication mechanisms, the security token may also be maintained at a data 
computing device(s) under control of the end user - e.g., through storage in any appropriate storage media - so that 
10 upon each subsequent service request it may be automatically attached to such a service request for submission to 
the sen/ice management domain. In other words, the tnitialisation of an authentication process for each single service 
request becomes obsolete. 

[0039] Further, it is found that it may be of benefit to summarize a plurality of different services and related requests 
into a service session. 

15 [0040] One typical example of such a service session may be a plurality of services being related to a Web browser 
and at least one plug-in where both the Web browser and the related plug-in modules request different sen/ices like 
browsing the Internet, audio and video services, etc. 

[0041] In particular, the consideration of a plurality of services as a session enables a facilitated handling of such a 
plurality of services in the service management domain. One example would be that one can easily check upon receipt 
20 of a service request whether a related service has already been started so as to avoid redundant initialisation of such 
a service. 

[0042] Further, in relation to each session context there is maintained the related user name, security token, a list 
of all activated services and related connection points to service hosts providing related services. This approach facil- 
itates a consistent redundancy-free maintenance of data being related to a plurality of services and a single end user. 
25 [0043] In view of this, the concepts outlined above - i.e., the provision of a security token to an end user which may 
use this token for initialisation of a plurality of services at a service management domain during a service session - it 
is clear that finally the end user may wish to terminate such a service session. 

[0044] Here, according to the invention the security token will be released by the service management* domain. In 
other words, according to the invention it is proposed to use the security token only over a limited period of time-or, in 

30 other words, in a temporary manner. 

[0045] This contributes significantly to increase of security within a service processing environment as it becomes 
practically impossible to decipher each single security token during the period of time where the security token is.valid, 
since - contrary to user names and user passwords which are maintained over a longer period of time - the time period 
where each security token is valid will be comparatively short. 

35 [0046] Further examples of the present invention relate to specifics of the session management domain. As -will be 
seen In the following, the session management domain handles both the administration of service context information 
and the triggering of services at at least one data processing device within the service management domain, also 
referred to a service host in the following. 

[0047^ Here, the session management domain may be embedded into a distributed computing environment where 
40 administration of session context information is assigned to a first data processing device - which may be referred to 
as entry or access server - and the provision of services is assigned to at least one further data processing device - 
which may be referred to as service host or server. 

[0048] In this case, a significant advantage is.that.an end user has only a single entry point into the session man- 
agement domain and that each and every data exchange thereto is handled only via such a single entry point. 

45 [0049] The above may be achieved through application of the client/server architecture within the framework of the 
present invention, where the session processing unit is assigned to the client and the session management unit is 
assigned to a server. In addition, the service host(s) may be provided as additional server(s) in the session management 
domain and be linked to the session management server - which may be without restriction of the present invention a 
Web server - via data communication networks like the Internet. 

50 [0050] According to an example, a first option is that - after successful authentication and provision of a security 
token to the client - a service request with the security token is then submitted to the Web server which then identifies 
the appropriate service host for activation of the related service. The service host may then run the service to generate 
related sen/ice data for feedback to the client, either via the Web server or in a direct manner. The former has the 
advantage that the client only exchanges data with the Web server, while in the latter case the speed of data transfer 

55 is accelerated due to direct interaction of the client and the service host. 

[0051] According to a second option, after a successful authentication the client handling the services at the end 
user side not only receives the security token but also at least one service connection point - i.e., an access point like 
an IP address or port number in the service management domain - for direct access to the service host after receipt 



5 



EP1 315 064 A1 




of security token. Thisrcffher enhances the speed of data communication and increases the efficiency of data exchange 
between the service handling domain and the service management domain. 

[0052] As outlined above, the support of a plurality of services within the framework of a service session is of impor- 
tance to achieve end user convenience. Here, one can easily imagine a situation where the request of a service requires 

5 a modification of the data processing system running the plurality of services at the end user side, typically the instal- 
lation of new software. One such typical example would be the use of a Web browser by an end user where the request 
for some specific sen/ice like audio or video requires the installation of a related audio or video plug-in into the browser. 
In a more general form, such a situation occurs when a main program necessitates the installation of an auxiliary 
program to enhance its capability. 

10 [0053] Such a situation may be handled by evaluating in a first operation, whether a new service requires the mod- 
ification of software installations at the data processing device supporting the end user, then to install the new software 
at the related data processing device and finally to assign the previously submitted session token - and optically service 
connection points - also to the newly installed software. 

[0054] A benefit of such a methodology is that besides a request for a new service the end user is freed from additional 
15 input of data as the new functionality and related software is automatically extended by the previously assigned security 
token which may then be used for receiving services being related to the newly installed software from the service 
management domain. 

[0055] The above solution also has the benefit that the very initial log-in dialogue may be realized via a Web display 
page being issued by a Web server. Therefore, the log-in dialogue fits perfectly into the look and feel of Web application 
20 (s) running In a distributed computing environment. Yet another advantage Is that this approach allows to reduce brows- 
er plug inside when at least part of the client components are plug-in modules as not each single plug-in module must 
realize a log-in dialogue functionality. 

[0056] According to another aspect there is provided a computer program and related computer program product 
directly loadable into the internal memory of a computer comprising software code portions for performing the inventive 
25 process. 

[0057] This allows an implementation of the above operations on computer or processor systems. Such implemen- 
tation leads to the provision of computer program products for use with a computer system or more specifically a 
processor comprised in, e.g., a client/server system. 

[0058] These programs defining the above operations can be delivered to a computer/processor in many forms. 

30 including, but not limited to information permanently stored on non-writable storage media, e.g., read only memory 
devices such as ROM or CD ROM discs readable by processors or computer I/O attachments; information stored on 
writable storage media, i.e. floppy discs and harddrives; or information convey to a computer/processor through com- 
munication media such as network and/or and/or the Internet and/or telephone networks via modems or other interface 
devices. It should be understood that such media, when carrying processor readable instructions Implementing the 

35 inventive concept represent alternate embodiments of the present invention. 

[0059] Within the embodiment shown in Fig. 1 the processing system 100 may be constituted by any kind of data 
processing device or combination of data processing devices, such as a general purpose data processing devices, a 
plurality of interconnected data processing devices, including client and server units, a mobile computing device, a 
personnel data organiser, a mobile communication device including a mobile telephone and similar. Similarly, the ses- 

40 sion management unit and/or session processing unit may be constituted by any kind of data processing unit or group 
of data processing units. 

[0060] Further, the data exchange between the session processing unit 110 and the session management unit 120 
may be achieved through any kind of internal or external communication link, e.g., communication networks such as 
local area networks, wide area networks, virtual networks or the Internet. Further, provision of data between the session 
45 processing unit 110 and the session management unit 120 may be obtained trough wireless communication links or 
fixed wired communication links, or any other communication means. In any case, standard protocols for access and 
or retrieval of data over a communication link may be employed, e.g., a communication standard such as HTTP (Hy- 
pertext transfer protocol) or similar. 

[0061] The security token may be any kind of information allowing an identification for the purpose of, e.g., obtaining 
50 a service or establishing a session. The security token may be constituted by any sequence of characters allowing an 
unambiguous identification for authentication purposes. Besides the provision of a character string as security token 
one might as well use a number as security token, or yet another alternative would be the use of a cookie, which is 
set when an end user connects to a server. Here, a cookie is unique for the connection of an end user to a server and 
it will be managed at the end user client side to specify a browser session. Yet another alternative would be the use 
55 of a plurality of security tokens for a single session or a combination of cookies and at least one security token for the 
handling of a single service session. In the latter case, the cookie will be used for access to the entry server in the 
service management domain, as the communication with this server is achieved via the browser and the further security 
token may be used for access to the service host. Further to the above, it should be clear that according to the present 



6 



EP 1 315 064 A1 0^ 

invention a security token may also be provided via a chip card or equlvalently smart card handed out to an end user. 
The end user may then plug in the smart card or chip card carrying the security token to any appropriate device sup- 
porting the services requested by the end user. While above, different examples for the provision of security tokens 
have been given, it should be clear that these are only examples for the present invention and not to be construed as 
limiting the present invention. 

[0062] Further, while above the submission of. e.g.. a user password and a user name for authentication has been 
given as one example for an authentication mechanism, it should also be clear that any other appropriate approach 
to authentication does well lie within the scope of the present invention. One such example would be the evaluation 
of biometric data like fmger prints, the scanning of an eye, and also physical means of authentication like use of keys, 
identification cards, etc. Again, all these examples well lie within the scope of the invention and do not either restrict 
or limit scope thereof. 

[0063] Even though, Fig. 1 shows the processing system 100 as single element, it is also possible that the function- 
alities of the session processing unit 110 and the session management unit 120 are provided at different locations, as 
may be the case in a distributed computer network like the Internet or a local area network. 

[0064] Further, insofar as data has to be stored in connection with operations of the processing system, this may be 
done at an external location such as a memory unit accessible through an external communication link, while other 
parts of data may be stored in components of the processing system 100, e.g., on a hard disk, a RAM or similar. In 
particular, modifications of data such as security token may be stored in an internal memory of a component of the 
processing system 100. 

[0065] Further, the different components discussed so far could be realised by a central processing system of a data 
processing system or by corresponding software operations or could be realised as a hardware device, located inside 
the processing system. Another example would be a combination of a software and hardware realisation. Moreover, 
it is possible, that the session processing unit 110 is partially or entirely arranged at a location external to the processing 
system. 

[0066] Further, it is noted that a computer- readable medium may be provided having a program embodied thereon, 
where the program is to make a computer or a system of data processing devices execute functions or operations of 
the features and elements for the above described example. A computer readable medium may be magnetic or optical 
or tangible medium on which a program is recorded, that can also be a signal, i.e. analogue or digital, electric,- magnetic 
or optical, in which the program is embodied for transmission. Further, a computer program product may be provided 
comprising the computerreadable medium. 

[0067] In the following, a further embodiment of the invention will be described with respect to Fig. 2. 

[0068] Fig. 2 shows a flow chart of the method according to the embodiment shown in Fig. 1 . 

[0069] As shown in Fig. 2, initially an end user submits a security code in a first operation 210, e.g., a user name 

and a password, for initially authentication. The initial authentication may include any authentication operation, including 

authentication operations known in the art. 

[0070] Then, in a subsequent operation 220, there is provided a security token when the authentication is successful. 
The security token may be generated by a session management unit, or may be obtained from another entity, including 
an entity external to the processing system, e.g., after successful authentication in operation 210. Further, the security 
token preferably includes information which cannot be inferred by a fraudulent user, and thus can be used as a proof 
of authorization. It is also possible that the security token is altered for each subsequent authentication before a desired 
service, e.g. according to an algorithm. This allows to further reduce the risk of fraud. A fraudulent user, even if eaves- 
dropping a security token used at one point for authentication, as the security token is continuously changed, could 
not use this version of the security token for authentication. 

[0071] Then, in a operation 230 the end user may use the security token for each subsequent service request without 
further authentication. This may involve an active submission by the user, however, for improved user friendliness, the 
security token could be automatically submitted for authentication. 

[0072] In case in operation 220 the authentication is not successful, the request for a service can be rejected. Another 
example would be that the end user is again requested for input of authentication information, e.g. to correct the user 
name and/or user password. According to another example, the authentication of the submitted user name and pass- 
word may be repeated at a later time. 

[0073] A session management unit or any other entity of the system may maintain session context information com- 
prising at least the security token assigned for the sen/ice session, the authentication information, a list of services 
activated during the service session, and a list of connection points to related service hosts. 

[0074] Further, the session context information may be maintained in a centralized manner at the session manage- 
ment unit. Alternatively, or in addition thereto, the session context information may be maintained in a distributed manner 
at one or a plurality of service hosts. 

[0075] From the above, it becomes clear that the provision of each service may be divided in end user specific data 
processing and further data processing which is not under control of the end user. The examples for the former would 
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be I/O functionality, dai^isplay functionality, local computing, etc. In the latter case, the functionality relates to the 
administration of user data, password data, and also the provision of service data like display data or data in response 
to a data base interrogation to the end user 

[0076] Therefore, the provision of a service or of services for an end user may be considered as falling into an end 
5 user specific service handling domain and into a service management domain not controlled by the end user, irrespec- 
tive of which are the examples given above for the processing of related tasks and exchange of data underlies the 
service provision. 

[0077] In the following, a further embodiment of the invention will be described with respect to Fig. 3. 

[0078] Fig. 3 illustrates an example for a service handling context where it is assumed that the service request 
10 initiated by the end user is - among others - related to a browser application. A browser application can be any program 

or group of application programs allowing a convenient browsing through information or data available in distributed 

computing environments such as the Internet or any other network including local area networks. A browser application 

generally allows to view and download data and further to transmit data between different data processing devices. 

Further, a browser application, appropriately configured or equipped with appropriate amendments or application mod- 
15 ules, sometimes termed plug-ins, may be enhanced with further functionality to access or process specific kinds of 

information available in a distributed system such as text documents, video Information, audio information or any other 

kind of information in specialised format. 

[0079] As shown in Fig, 3, such plug-ins are additional examples for what might be related to a service request. A 
plug -in may generally be a piece of software which may be added to any kind of larger software application, such as 

20 a browser application, the above exemplary text processing application or any other service application. A plug-in adds 
the defined functionality of the larger software application, for example visualisation capabilities for certain types of 
documents, specific processing capabilities or similar. A plug-in may be added to the larger software application gen- 
erally at any desired time, provided that the larger software application is equipped to receive and Integrate the plug- 
in. The code for the plug-in may be obtained from any source, such as over a computer network, from a data storage 

25 medium or similar. Alternatively, a plug-in may also be a piece of hardware adding functionality to an application or 
larger hardware structure or a combination of auxiliary soft- and hardware to enhance overall functionality. 
[0080] From Fig. 3 it becomes clear that, generally, service handling with respect to an end user may be related to 
different services requested by the end user where different services relay on different application modules, e.g., pro- 
viding browser and/or plug-in functionalities. Underlying this level abstraction, there exists a further service provision 

30 related level, i.e. being related to the question to which data processing devices - e.g., web service - applications 
running at the end user size will actually carry out access to for receiving sen/ice data in response to a sen/ice request. 
[0081] In the following, a further embodifnent of the invention will be described with respect to Fig. 4. 
[0082] Fig. 4 illustrates service management as counterpart to end user oriented service handling. With respect to 
management of different services, Fig. 4 illustrates that a management of different services is achieved through es- 

35 tablishment of sessions that constitute a summary of different services with respect to a single end user into a service 
session. One typical example of such a service session may be a plurality of services being provided to the end user, 
e.g. web browser related services and plug-in related services, as exemplified with respect to Fig. 3. 
[0083] Fig. 4 illustrates that session management relates to the administration of a plurality of session related data 
for different end users. Each single end user runs a session and for the session management related data is maintained 

40 as session management context, i.e. the related user name and user profile. Here, user profile may be static or dynamic 
data classifying the end user with respect to authorisation for access to services, preferred data exchange formats, 
user priority, etc. Each session management context also comprises the security token which has been returned to the 
end user upon successful authentication, and further a list of activated services and related connection point to the 
service providing data processing systems, once a security token has been provided. In addition to that, according to 

^5 another example the session management contact may also comprise a list of services supported so far - e.g., through 
installation of related application modules or application software at the end user side. 

[0084] It should be clear, that each single session management context may be maintained in a random access 
memory but could also be maintained on a permanent memory, allowing to still access the session management context 
after a complete shut down of a related data processing system. Upon resuming operations, it may be then possible 

50 to reload the session management context for subsequent analysis of information with respect to different services 
provided to different end users, to proceed with the provision of modifications after resumption of services. 
[0085] In the following, a further embodiment of the invention will be described with respect to Fig. 5. 
[0086] According to the embodiment shown in Fig. 5, it is proposed to submit a security code of any kind as outlined 
above in an operation 510. After a successful initial authentication in operation 510 there is then provided a security 

55 token in combination with at least one connection point to services in operation 510. Optionally, there may be the 
possibility to select from a plurality of service hosts for provision of services in response to a submitted service request 
in operation 530. Such a best available service host may be selected on the basis of available connection points 
provided in operation 520. A benefit of such a selection mechanism is the possibility to achieve a load balancing 
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between a plurality of service hosts providing a plurality of services to different end users. A further example is to assign 
a specific service to a specific service host within the service management domain. Yet another example would be to 
assign at least one end user to a specific service host. Still, another example would be to assign a specific end user 
group to either at least one service host or a group of service hosts in the service management domain. All these 
examples are to be considered as non-lim'iting for the scope of the present invention. Once a service source is available 
in response to a submitted service request, in operation 540 then the security token and the appropriate connection 
point to the related service host will be used for subsequent sen/ice processing without further authentication, as already 
outlined above. 

[0087] In the following, a further embodiment of the invention will be described with respect to Fig. 6. 

[0088] The embodiment illustrated in Fig. 6 relates to the termination of a service session, or in other words to the 

release of session -related data and disconnection of session-related connections. 

[0089] Initially, in operation 610 the end user will indicate that he wants to release a session through submission of 
a related request. Then may follow the optional operation 620 to finalize activated service(s) and the further optional 
operation to save service-related data to avoid waste of already used processing time. Then, in operation 640 the 
session -related connections between the session management domain and the service processing domain and further 
to a service host are disconnected and in operation 650, optionally, session management contact data may be saved, 
e.g., for the reason of debiting, auditing, and/or service recovery. Of course, operation 640 and 650 may as well be 
reverse. Finally, in operation 660 the security token may be released for subsequent use in a further service session. 
[0090] The embodiment illustrated in Fig. 6 shows that according to the present invention one may choose freely 
between a direct and immediate shutdown of a service session upon request or on the other hand a consistent, secure 
and documented session shutdown. Which one is appropriate may depend on the kind of services. E.g., for banking 
services, it may be used to carry out the optional operation 620, 630, 640, while less security-specific services like 
audio/video games may allow for an immediate shutdown upon end user requests. 

[0091] While above, the efficient support of a single authentication and the related shutdown of a service session 
has been discussed, it should be noted that also the handling of security tokens during the on-period of such service 
sessions allows for the implementation of valuable mechanisms for support of end users. One example would be to 
take specific care of security-sensitive services, like remote banking, remote access to personal-bound data, etc. Here, 
one example for security token management would be to block the allowability of the security token at the seission 
management domain after a service-specific period of time. E.g., one could imagine that a security token provided for 
remote banking will be blocked after an hour so that after a relatively short period of time no person has access to 
such a banking account. A further example would be to change a security token during an ongoing session management 
through repeated provision to the end user without repeated authentication. In other words, the end user is repeatedly 
provided with security tokens at certain points in time without repeated authentication to increase the security level for 
the ongoing service session. Yet another example for the handling of security tokens could be that the security tokens 
are provided in a way dependent on the area of application, e.g., in a way that each security token is only provided for 
a specific country, region in a country, etc. Yet another example for security management would be that for charged 
services a security token is only provided when the requesting end user has previously deposited a sufficient amount 
of money with the service provider in the service management domain. Here, one could imagine that a continuous 
monitoring of the deposited service compensation amount is achieved in the service management domain and that a 
security token provided to the end user is blocked once the amount of money is no longer enough to pay for the 
requested services. All the examples given above for the security token management are non-limiting for the scope of 
the present invention and only serve to illustrate the applicability thereof. 

[0092] Fig. 7 illustrates examples for the interrelation between the session handling domain/context illustrated with 
respect to Fig. 3 and the session management domain/context illustrated with respect to Fig. 4. Here, an example 
would be the application of the client/server architecture where session handling is achieved through at least one client 
data processing system and session management is achieved through at least one server data processing system. 
The client data processing systems then set up a session handling domain, while the server data processing systems 
set up the session management domain. Further, in the session management domain there may be the server or 
plurality of servers handling session management as exemplified with respect to Fig. 4 alone, while further servers 
provide services and related response data on requests of the end user. The latter sen/ice will also be referred to as 
service host in the following, i.e. as a data processing device that acts as a source of information or signals. 
[0093] As illustrated in Fig. 7 there exists a plurality of options how to proceed with service handling, service man- 
agement and service hosting: 

[0094] According to a first example the session context for a plurality of end users may be administered in a central- 
ised manner, i.e. at a single session management server. The session management server then handles the authen- 
tication of the end user for submission of a related token back to the service processing domain. Upon retransmission 
of the assigned security token from the session processing domain, i.e. the client data processing system available to 
the end user, the session management server will then verify the security token. It should be noted that this operation 
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.ay .e optional and ^.e o.itted as we,, to the^p^^^^^^^^^^^^ by . 

100951 Further, the session management server w. '^^"^ fny other server data processing system in the f 
he end user which may be the session management ^^J^ be forwarded thereto, 

session management domain. Having '^^^f '^^^"^^^^^^^^ host has the option to either directly 

=he^=^re=rst r^^^ 

on,y a singie access P°*nt to the session mana^^^^^^^^^^ ^^^^^^ Here, session 

[0097] Another option illustrated in Fig. 7 so that each single data processing system 

Lnagementdata maybe distributedoverthese^ionm^ 

- e.g., each server in the session management '^o'^f appropriate service host and forwards the 
100981 Here, the session "management server only has to^^ if 
'service request(s) thereto. Then, verification host is optional, 

required. In other words, the verification of t'^^^^"''":^^^^^ host again two options exist for re- 

[0100] Accordingly, a service host for each service ^^^^ J^^e forwarded to the identified service host. 

of ths seivlo. wuesl M the se™oe hosi lor f ""f^^"' '°™" , J,„ ,„eot a direct forwaiaing of service dau frorr, 
10102) Moreover, tire sesaionmarragerner urr* ™, be a^^^ 

!t,e service hos, to ttre session '"'^'''•?TZ,^^ °^^SS^f^^>^''V ""it » by any otfte, rrrean.. 
Sro^T^n— r,o,,he.«,.=dau,.e„,,ca.— 

management domain. submit a service request but also have direct access to 

[0105] An end user requesting a service may then not l2,TnL Z Lry\ce^osX may verify the security token - 
ihe related service hosts through the related f data to the session handling 

r^^irai^rrn^^^^^^ 

[o'lOeT '^r^lZ^'L^er option where the security toKen and related connection points are available in the 
session processing domain. hotwppn a session management server and a service host. 

101071 Here, the processing of a service request is ^P'^ ^^^^tto^pc^m^^^^ are fon«arded to the sendee host, which 
The security token and the related sen,ice '^'^^^^^^1''^^°^^^^^ 

r ^^^^^^ - °^ ^^^'^^ ^^^""^^ 

JoTosi processing di^erent scenarios for - "nt^e-^^^^^^^ ~- 

domain have been explained with respecttothe ^^^f ^te ^rthrSte^ of a session context in the session 
agement domain. Further examples of '"venhon rela^ to the^m^^^^^^ 

management domain and the way how service 7^=P°"^^^^^^^^^^ in the session handling domain, e.g.. 

TiSa^onTar l^L^^^^^^^^^^ -tem. e.g.. a client, used by the end 
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side, e.g.. into the session management context and then to compare a submitted serviceTequest with this list of 
1^ supported services. Alternatively and as shown in Fig. 11(b), also the service host may - upon processing of service 
^ request - carry out an interrogation at the session management domain. Yet another example for realizing the interro- 
gation operation 1010 shown in Fig. 10 is illustrated in Fig. 11 (c). Here, upon initialization of a sen/ice request, initially 
5 it is checked in the session processing domain whether the requested service is already supported. If the result of this 
operation is *no\ initially the related application module or software is installed in the session processing domain - as 
will be explained in more detail in the following - and only then the service request and security token may be submitted 
to the session management domain or alternatively to the service host. 

[0112] Referring again to Fig. 10, when the interrogation operation 1010 leads to the result that a new application 
10 module is necessary, this new application module may then be installed at the end user side in operation 1020. Again, 
it should be clear that the application module may be either provided in hardware or in software. In the latter case, the 
application software may be provided through downloading from the session management domain or from an external 
storage media for which examples have already been given above. 

[0113] A further operation 1030 shown in Fig. 10 is related to the assignment of the session token already available 

15 before operation 1010 to the newly installed application module. Optionally, also service connection points may be 
assigned to the application module. The outcome of operation 1030 is that upon activation of the newly installed ap- 
plication module the application module may not only generate a service request but also extend the service request 
by the assigned session token and optionally service connection points for the submission to the service management 
domain. Therefore, all operations necessary for the activation of a requested service at the end user side may be 

20 achieved without interrupting the flow of service processing at the end user side, particularly without requesting a 
repeated authentication also for the newly installed application module. Therefore, after assignment of the session 
token to the newly application unit a further operation 1040 is the return to service processing. 
[0114] In the following, a further embodiment of the invention will be described with respect to Fig. 1 2. 
[0115] Fig. 12 shows a client server system using a single authentication process for a plurality of services already 

25 explained above. The client service system 1200 divides into at least one client unit 1210 and at least one server unit 
1 220. Without limiting the scope of the invention, one may assume as one example thereof that the client unit realizes 
the service processing/handling domain and that the server unit 1220 forms part of the session management domain. 
Further, as shown in Fig. 12, the client unit 1210 has a display unit 1230, a service application unit 1240, a token unit 
1250, and a log-in unit 1260. Operatively, the display unit may display l/O-related and service-related data to the user 

30 of the client unit 1 210. Further, the service application unit supports all processing with respect to provision of services 
to the user of the client unit 1 210. Further, the token unit 1250 supports all functionality described above with respect 
to the security token, and the log-in unit 1260 supports all functionality being related to the authentication of an end 
user, as outlined above. 

[0116] As counterpart to the log-in unit 1260 of the client unit, Fig. 12 shows that also the server unit 1220 has a log- 
35 in unit 1270 for reception of the authentication request from. the client unit 1210 and forwarding to the authentication 
and session management unit 1280. In addition, the server unit 1220 comprises a service management and context 
unit. Operatively, the log-in unit 1270 in the server unit 1220 is the low level unit for reception of authentication infor- 
mation at the server side. On a higher level of abstraction the authentication unit will then verify the submitted authen- 
tication request for submission of a security token back to the client unit 1210. Optionally, the authentication unit and 
40 session management unit 1280 may also provide. service connection points to the client unit 1 210. Further, the service 
management unit 1290 may also maintain the context of a session as explained with respect to Fig. 4. 
[01 1 7] While above different units both of the client unit 1210 and the server unit 1 220 have been explained, it should 
be clear that these units may as well be combined with each other or split up into further units. Also, each single unit 
may either be realized in hardware or in software or in a combination of hard- and software. Further, the client server 
^5 system explained with respect to Fig. 12 may be adapted to any distributed computing environment known in the art, 
i.e., local area networks, wireless LAN networks, or any other kind of system relying on the client server paradigm. 
[0118] In the following, different examples for the application of the client server architecture shown in Fig. 12 will 
be described with respect to Fig. 13. 

[0119] Fig. 13 shows an example for the interaction of the service handling domain and the service management 

50 domain, with a more detailed reference to a distributed client server system. 

[0120] As shown in Fig. 13 the session handling domain divides into a plurality of client processing systems 1310, 
1320 and a plurality of server processing systems 1330 to 1380 in the session management domain. Without limiting 
the present invention it may be assumed that one of the server processing systems, i.e. sender 1380, is an entry server 
to the session management domain. The further servers In the session management domain 1330-1370 are servers 

55 acting as service host(s). 

[0121] As also shown in Fig. 13, the change of data between the session handling domain and the session manage- 
ment domain and also within the session management domain may be classified into different categories. A first cat- 
egory is the exchange of authentication and session management related data (solid line), further, the exchange of 
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session manaqemenWted data within the session management domain (dashed line), and the exchange of service 
pay^ad d'a both within the session management domain and between the session handling domain and the sess.on 

^0^2^ rS'u^tXrpt 13 enh" one of the clients 1310. 1320 initially sets up a communication dialogue with 
t'SI^nUy^rlerTSolorexc^angeofauthentica^^ 

on connection points, i.e., numbers assigned to application running on the service hosts 1330 o 137a Subsequen 
herSo an example for the present invention would be that client unit 1310 requests a service from the entry serve 
^380 which maXen - after verification of a submitted security token, forward the service request to the service host 
Having pmcessed the service request, the service host 1 330 may then directly feed back the service response 

foias? 'Anofhrexlmple Shown in Fig. 13 would be that the entry service 1380 receives a service request from the 
Eunin320 Lnd'^i^ards the servL request to the service host 1360. After generation of the service response 
dSthelr^icehL 

;012y''AlThl'exlmplebeing related to the distribu^^^ 

wlw be^hi thL entTserver 1380 receives a service request and related token from the client 1320 and fon«ards 
Th^ da^ ifttut v'eSion to the service host 1370. Then the service host 1370 may verify the submitted security 
token and directly respond with the related response data to the client unit 1 320. 

S Th distributed client/server system supports flexibility in service P™^;,.^-^ - V^he'^^^^^^^ 
that drfferent clients - i.e. different end users - are handled with different priorities. In this case the entry server 1380 
ZoMsetl To a priority queue putting in the clients with higher priority before clients with lower priority. 
r01261 Anoth^ be the fmplementation of a load balancing mechanism for the handling of service 

eJSls ;rn sesLn management domain. Here, before fon^arding a -;'3-^^^^^^ 
host the entry server 1380 may initially determine the load on each single service host 1330 to 1370, the availability 
oUhe requeld se^^ at each service host 1330/1370, and then select the service host providing the requested 
service and having the lowest current processing load imposed thereon. ^ , • • 

iOA2^ Yet another example would be to specify a security token together with a preferred sub-domain in the session 
manaaement domain for the processing of services requested using the security token. 
S^zS Tstura so be noted thatthedistribut 

S only on a single authentication operations although further plug-in functionality may be ^^^^^^Jn *h's ca^^ 
f the browser is equipped with the appropriate remote visualization protocol or run-t,me environment component serv- 
cedatar^clis^y to authenticate a specific end user may be retrieved from an arbitrary storage locatK^n. appropriately 
rendered by a auS application located at the entry server and displayed at the clients in a browser frame on 

roiSr^rremote visualization protocol or run time environment component seivice is to ensure convenient access 
tram a firS Smputer system to resources available at a second computer system - in the present example, any appl. 
cTon or group of applications or modules which enable a user at a client unit to communicate with a server umt in the 
serl°ce managemen'domain for new information provided by a server in the server management do-^^. ^-a J^^ 
en^ se^er For example, a remote visualization protocol or run-time environment componentserv.ee may enable an 
SJer to connect to the entry server, to control an application such as the above exemplary authentica ion application 
1 the ent^sei^er and to view processing results such as a log-in display window. A remote visualization protoco or 
%n:r::ZZZL^corupoJ.t service may cooperate with a browser application to ^'Z^^'^l^^'':'^^^^^^ 
Here, the benefit is the achievement of a single look and feel for the end user both tor authentication and for running 

raTsof An example of a run time environment component service is disclosed in the European patent application EP 
^36 9. entmed -Run Time Environment Component Services" and fited on January 15, 2001. which is incorpo- 

[oi?ir A^oXTan end user would be able to authenticate, through use of a browser, to the sessfon management 
domain to achieve a very convenient look and feel for the end user. 

[01 32] In the following, a further embodiment of the invention will be described with respect to Fig. 14(a) and 14 b)^ 
[01 33] Figs, 8(a) and 8(b) illustrate further examples of the inventive authentication mechan^m running in a distrib- 
uted client service system on a more detailed level. „«u„ Pliant I mitanri 
[0134] AS outlined above, data processing system involved in the authentication mechanism ^^^/h^cl^^^^^^^^^ 
the entrvserver Initially, an operation 1401 establishes a session set up between a client unit and the entry server, 
misi Thrihe S server receives a user input tor authentication in operation 1402 and generates an authenti- 
ca ion requeifo: transmission to the entry server in operation 1403. In the related operatton 1*04 the entr^^ 
receives the authentication request and prepares a display frame for authentication display and transmission to the 
client unit in operation 1405. 
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[0136] Then, in operation 1406 the client unit receives and displays the authentication frame for subsequent user 

• input of authentication data, e.g., user name and password. Another example would be that the display frame is gen- 
erated locally at the client unit for display in operation 1406 for reduction of amount of data to be exchanged between 
the client unit and the entry server. 
5 [01 37] Then, in operation 1 407 the user inputs the actual authentication data like user name and password for trans- 
mission to the sen/er. In the related operation 1408 the entry server will receive the authentication data and verify this 
data for the client user. Then, in operation 1409 the entry server evaluates whether the authentication has been suc- 
cessful. If the result is 'no*, the entry server forwards related information to the client unit which will then handle the 
rejection of the authentication request in operation 1410. Here, one option for handling the rejection is to prompt the 
10 user again for input of the authentication data so that the user has the option to correct the data. Another option would 
be the closing of the session between the client unit and the entry server 

[0138] If the result of the operation 1409 is Yes, the entry server will then establish a session context and generate 
a security token for transmission to the client unit in operation 1410. The operation of generating the security token 
may employ any technique to obtain a piece of information allowing an unambiguous identification for authentication 

15 purposes, and may include techniques known in the art. In response to operation 1410 the client unit will receive the 
security token for subsequent maintenance in operation 1411. Here, a first option for maintenance of the received 
security token may be the storage in the working memory of the client unit, further the storage in a data file or the 
storage in a storage media external to the client unit. Optionally, together with the security token also session related 
data like service connection points may be maintained for the client unit for subsequent speed of service host access. 

20 [0139] Then, as shown in Fig. 14(b), in operation 1412 there is a continuous evaluation whether an end user has 
submitted a service request to the client unit. If the result is No, the interrogation operation 1412 will be repeated. 
Otherwise, if the result is Yes, the process flow will proceed to operation 141 3 to evaluate whether the requested service 
requires the installation of a new application module at the client unit. 

[0140] If the result of the interrogation operation 1413 is 'yes\ then the necessary application module will be installed 
25 at the client unit during operation 1414, as exemplified above, with respect to Fig. 10. Subsequent hereto, the service 
processing proceeds to operation 1415 to generate a service request including the security token for transmission to 
the entry server. 

[0141] According to a first scenario the generated service request will be forwarded to the entry server which then 
evaluates and verifies the submitted security token in operation 1416, and after Identification of an appropriate service 

30 host fonwards the service request to this service host in case the verification is successfu I in operation 1 41 7. In operation 
141 8 the service host will then generate the service response data and fonward the service response data to the client 
unit. In operation 1419 the client unit receives the service response data for local processing at the client unit. - 
[0142] A second scenario illustrated in Fig. 1 4(b) is the direct forwarding of a service request from the client unit the 
service host. According to this scenario the service host receives the service request with the security token for eval- 

35 uation of the allowability of the submitted request on the basis of the submitted security token in operation 1 420f If the 
result of the evaluation is positive, the service host then proceeds to operation 1 41 8 for further processing of the service 
request, as previously explained. Othenwise, the service host may reject the submitted service request. 
[0143] Further, subsequent to the handling of the service response data in operation 1419 at the client unit there 
follows an operation 1421 for checking a log-out instruction at the client unit. Here, log-out may be related to a session 

40 on the one hand or to a shut down of the client unit itself. If the result of the operation 1421 is 'no', the process flow 
may branch back to operation 141 2 to check on further service requests at the client unit. If the result of the operation 
1421 is 'yes', the client unit will inform the entry serve about the log-out instructions. In operation 1422 the entry server 
will then generate and transmit a request to terminate the session including the release of the security token to the 
client unit. Further, for the example distributed session context is explained above with respect to Fig. 7 the entry server 

45 will also inform all servers in the session management domain maintaining the related session context about the service 
session shut down. Then, in operation 1423 the entry server will release the security token and the session context. 
In other words, once the security token is released it may be used for a further service session set up. The temporary 
characteristic of the security token increases security within the service management domain since only the time period 
where the session context is maintained at the entry server or any other data processing device within the session 

50 management domain may be used with this security token. 

[01 44] While above different examples and embodiments of the invention have been described with reference to the 
drawing it is to be understood that these are non-limiting to the scope and gist of the present invention and that a 
person skilled in the art is readily prepared to realize such modifications and variations. A first example for this is that 
while above a session has been described with respect to a plurality of services it may also be possible to set up a 

55 single session for each requested service. Further, it may be possible to use a single security token for a plurality of 
end users, thus achieving a shared token mechanism which is of particular advantage for services shared by a plurality 
of end users, e.g. video games, shared data base maintenance, etc.. Another example would be the provision of the 
same security token to the same end users logging in at a plurality of client units in the. session handling domain to 
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avoid maintenance of^^urality of service management contexts in the service management domain. 
[0145] According to another example, a session management unit may have the following constitution: 

1) Session management unit for managing a plurality of services including 

- a code section having instructions to receive authentication information from a session processing unit adapted 
to handle a service session divided into a plurality of services, upon initialisation of a first service, and 

- a code section having instructions to return a security token for initialisation of each subsequent service of the 
service session without repeated submission of authentication information. 

2) Session management unit according to 1), including a code section having instructions to return the security 
token to the session processing unit only after successful verification of the authentication information. 

3) Session management unit according to 1 ). including a code section having Instructions to identify a service host 
for each service request submitted by the session processing unit and to forward the service request to the identified 
service host. 

4) Session management unit according to 3), including a code section having instructions to receive service data 
in response to the processing of the service request at the service host for subsequent fonwarding to the session 
processing unit. 

5) Session management unit according to 3), including a code section having instructions to effect a direct for- 
warding of service data from the service host to the session processing unit in response to the processing of the 



service. 



6) Session management unit according to 1), including a code section having instructions to maintain session 
context information comprising at least the security token assigned for the service session, the authentication 
information, a list of services activated during the service session, and a list of connection points to related service 
hosts. 

7) Session management unit according to 6). including a code section having instructions to maintain the session 
context information in a centralized manner at the session management unit. 

8) Session management unit according to 6), including a code section having instructions to maintain the session 
context information in a distributed manner at the service hosts. 

9) Session management unit according to 1), including a code section having instructions to return at least one 
service connection to a service host in addition to the security token for direct contact of the session processing 
unit to the at least one service host. 

10) Session management unit according to 1), including a code section having instructions to effect set-up an 
authentication window for input of authentication data at a display. 

1 1 ) Session management unit according to 1 9), including a code section having instructions to effect set-up of an 
authentication window as a browser window. 

12) Session management unit according to 1), located at a server side, and including a code section having in- 
structions to remotely communicate with the session processing unit, the session processing unit being located at 
a client side. 

According to another example, a session processing unit may have the following constitution: 

13) Session processing unit for handling a service session divided into a plurality of services, including 

- a code section having instructions to transmit authentication information to a session rhanagement unit upon 
initialisation of a first service; and 

a code section having instructions to receive a security token for initialisation of each subsequent service of 
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the service session without repeated submission of authentication information. 

14) Session processing unit according to 13), Including a code section having instructions to receive the security 
token at the session processing unit only after successful verification of the authentication information. 

15) Session processing unit according to 13), including a code section having instructions to effect identification 
of a service host for each service request submitted by the session processing unit and for effecting forwarding of 
the service request to the identified service host. 

16) Session processing unit according to 15), including a code section having instructions to receive service data 
in response to the processing of the service request at the service host from the session management unit. 

1 7) Session processing unit according to 1 5), including a code section having instructions to directly receive service 
data from the service host in response to the processing of the service. 

18) Session processing unit according to 13), including a code section having instructions to effect maintenance 
of session context information at the service management unit, comprising at least the security token assigned for 
the service session, the authentication information, a list of services activated during the service session, and a 
list of connection points to related service hosts. 

19) Session processing unit according to 18), including a code section having instructions to effect maintenance 
of the session context information in a centralized manner at the session management unit. 

20) Session processing unit according to 18), including a code section having instructions to effect maintenance 
of the session context information in a distributed manner at the service hosts. 

21) Session processing unit according to 13), including a code section having instructions to return at least one 
service connection to a service host in addition to the security token for direct contact of the session processing 
unit to the at least one service host. 

22) Session processing unit according to 13), including a code section having instructions to evaluate, whether a 
new service request requires a new application module, further to install the new application module at the session 
processing unit in the affirmative case, and to assign the session token and optionally service connection points 
to the newly installed application module. 

•* 

23) Session processing unit according to 13), Including a code section having instructions to set-up an authenti- 
cation window for input of authentication data at a display. 

24) Session processing unit according to 22), including a code section having instructions to arrange the authen- 
tication window as browser window. 

25) Session processing unit according to 13), located at a client side, and including a code section having instruc- 
tions to remotely communicate with the session management unit, the session processing unit being located at a 
server side. 



Claims 

1 . Session management unit for managing a plurality of services, comprising: 

a reception unit for receiving authentication information from a session processing unit adapted to handle a 
service session divided into a plurality of services, upon initialisation of a first service, and 

an authentication unit for returning a security token to initialise each subsequent service of the service session 
without repeated submission of authentication information. 

2. Session management unit according to claim 1 , wherein the authentication unit returns the security token to the 
session processing unit only after successful verification of the authentication information. 
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, ^loim 1 nr 9 further comDrising a service management unit for identifying 

request to the identified service host, 
processing unit. 

to related service hosts. 

ir.torm.lton In a centrallz«l mann«r at ihe sesston management unit. 

S.a,tonmanagen»nt.n„acco,<r,n,toc,a,n,e.»h,te,n,n,c»ntextun««,ectsn»,nten.nc.o,tnesess-^ 
information in a distributed manner at the service hosts. 

■ r==ttss;fr."=:r™^^^^^^^ 

least one service host. 

0. session management .nit according to one o, — ^ ^^"^^ °' 

authentication »indow lor Input ol authentication data at a display. 

„. session management un« according ,0 one o, the ..alins , to ,0. wheiein the sen,.=e management un„ provides 
at least one ot tlie sen/Ices In a sen/Ice session as web seivice. 

session management un« accolding to Calm ,0 0,,., v*ereln the autn,n«catlon un. ettects set-up otthe au- 
thentication window as browser window. 
„ sesston management unH according ,o Calm „ or ,2^«n,reln the « teast one Wet. se™K=e Is a browser tor 
browsing through data In a network of data processing devMs. 

"•sro.:===~--^^^^^^^ 

side. 

15. session processing unit for handling a service session divided into a plurality of services, comprising: 

. a ..gin unit for transmission of authentication information to a sess«n management unit upon initialisation of 

a first service in a service session; and 
. a toKen unit for receiving a security toKen to initialise each subsequent service of the service session w«hout 
repeated submission of authentication information. 

Srrn=^rs:rrrsrmra.'rjrp=^^^^^ 

to the identified service host. 

^- f M^\rry 17 wherein the service application unit receives service data in re- 
18. Session processing unit according to claim 17, wherein tne service dpp 
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sponse to the processing of the service request at the service host from the session management unit. 



19. Session processing unit according to claim 17, wherein the service application unit directly receives service data 
from the service host in response to the processing of the service. 

20. Session processing unit according to one of the claims 1 5 to 19, wherein the service application unit effects main- 
tenance of session context information at the service management unit, comprising at least the security token 
assigned for the service session, the authentication information, a list of services activated and/or supported during 
the service session, and a list of connection points to related service hosts. 

21. Session processing unit according to claim 20, wherein the service application unit effects maintenance of the 
session context information in a centralized manner at the session management unit. 

22. Session processing unit according to claim 20, wherein the service application unit effects maintenance of the 
session context information in a distributed manner at the service hosts. 

23. Session processing unit according to claim 15, wherein the service management unit returns at least one service 
connection to a service host in addition to the security token for direct contact of the session processing unit to 
the at least one service host. 

24. Session processing unit according to one of the claims 1 5 to 23, wherein the service application unit evaluates, 
whether a new service request requires a new application module, further installs the new application module at 
the session processing unit in the affirmative case, and assigns the session token and optionally service connection 
points to the newly installed application module. 

25. Session processing unit according to one of the claims 15 to 24, wherein the service application unit sets up an 
authentication window for input of authentication data at a display. 

26. Session processing unit according to one of the claims 15 to 25, wherein at least one of the services of a service 
session is a Web service. 

27. Session processing unit according to claim 25 or 26, wherein the authentication window is arranged as a browser 
window. 

28. Session processing unit according to claim 26 or 27, wherein the at least one Web service is a browser for browsing 
through data in a network of data processing devices. 

29. Session processing unit according to one of the claims 15 to 28, which is located at a client side, and adapted for 
remote communication with the session management unit, the session processing unit being located at a server 
side. 

30. Method for managing a plurality of services at a session management unit, including: 

receiving authentication information from a session processing unit adapted to handle a service session divided 
into a plurality of services, upon initialisation of a first service, and 

returning a security token for initialisation of each subsequent service of the service session without repeated 
submission of authentication information. 

31. Method according to claim 30, including returning the security token to the session processing unit only after 
successful verification of the authentication information. 

32. Method according to claim 30 or 31, including identifying a service host for each service request submitted by the 
session processing unit and forwarding the service request to the identified service host. 

33. Method according to claim 32, including receiving service data in response to the processing of the service request 
at the service host for subsequent forwarding to the session processing unit. 
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processing unit in response to the processmg of the service. 

r:Lpp:2"2:s~.- «o,con„.^" ^-.o — 

the session management unit. 



service hosts. 



authentication data at a display. 



service. 



in a network of data processing devices. ^ 



30 unit. 



„ Me,^. — ,0 o,a,n, 30, ... »„a. o, . .,».«y « « - »' ' 

35 IS activated. , 

before release of a security token. 
. „.Me.o.aooo,..»...4e.«.e.nc.-..e=3..o,=.a»noo«,«— n»...a.....»o.^ 

token. . 

. „«.„,a,eo.,.«en..,n«a.o„o-a.*.^^«e™-on..s,.^»ss.n.«o.uepa^ 
submission of authentication information. 

« .3 .c..,. -o c,a,. lnc«. - « — * 

ruocessfulv«moa>ionotlheautl.«lcat«.nrt<,rmalion. 



55 host 



at the service host from the session management unrt. 



18 



EP1 315 064 A1 

52. Method according to claim 48, including direct receiving of service data from the service host in response to the 
1^ processing of the service. 

53. Method according to one of the claims 48 to 52, including effecting maintenance of session context information at 
5 the service management unit, comprising at least the security token assigned for the service session, the authen- 
tication information, a list of services activated and/or supported during the service session, and a list of connection 
points to related service hosts. 

54. Method according to claim 53, including effecting maintenance of the session context information in a centralized 
10 manner at the session management unit. 

55. Method according to claim 53, including effecting maintenance of the session context information in a distributed 
manner at the service hosts. 

15 56. Method according to claim 48, including returning at least one service connection to a service host in addition to 
the security token for direct contact of the session processing unit to the at least one service host. 

57. Method according to one of the claims 48 to 56. including evaluating whether a new service request requires a 
new application module, further installing the new application module at the session processing unit in the affirm- 

20 ative case, and assigning the session token and optionally service connection points to the newly installed appli- 

cation module. 

58. Method according to one of the claims 48 to 57, including setting up an authentication window for input of authen- 
tication data at a display. 

25 

59. Method according to one of the claims 48 to 58, wherein at least one of the services of a service session is a Web 
service. 

60. Method according to claim 58 or 59. including arranging the authentication window as a browser window. 

30 

61. Method according to claim 59, wherein the at least one Web service is a browser for browsing through data in a 
network of data processing devices. 

62. Method according to one of the claims 48 to 61 , wherein the session processing unit is located at a client side and 
35 the session management unit is located at a server side and remotely communicates with the session processing 

unit. 

63. A program having instmctions for carrying out the method of at least one of the claims 30 to 62. 

^0 64. A computer readable medium, in which a program is embodied, where the program is to make a computer execute 
the method of at least one of the claims 30 to 62. 

65. A computer program product comprising the computer readable medium according to claim 66. 

45 
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